Reuse the Effect runtime revision during Lark admission - #8314

Reviewer: model_agent, gpt-6.1-sol, OpenAI, runtime_reported, reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

Lark 入口接收来自原 App 的事件，需要快速建立或读回原 Turn，并在绑定变化时可靠拒绝。 在基线和当前 head 对四个独立事件各做准入与同事件重投，并在另一个事件读来源时撤销绑定。 在同一合成 workload 下，首次准入的实际版本解析从 13 次降到 1 次，后三个新事件从各 6 次降到各 1 次，四次重投从各 2 次降到各 1 次。 在 provider source read 中途撤销原绑定，两边都返回 command_rejected，均无新 Turn 或投递；四次重投仍各只有一条原 Session/Turn 的用户消息。 完整核对 2 个变动文件；代码路径只改 admit，相关准入和原会话行为由本地真实 Core 验证。 本轮为本机隔离验证；真实 Lark provider、生产锁尾延迟与分发后的观测仍待单独验证。

改动思路 / Approach

Lark 入口的现有同步 admit 加入 revision scope；同一调用中的 Core 读/写共享版本。ContextVar 在 finally 关闭并清除，下次独立调用重新解析。源码/权限的持久 owner 不变。 直接复用已经存在的 request scope；它只固定 executable revision 和现有纯投影缓存，不缓存绑定、来源或 canonical write。没有新增 owner 或状态格式。 已有 Lark 路径内部性能修复；不改变 provider 启用、出站验证、宿主选择或 release gate。

具体改动 / Changes

基线为 e2371c476805f67903dd3c338a7e2712f577c9cc。现有迁移 RFC 要求每次逻辑请求固定可执行版本；绑定、provider 与权限仍需实时读取。Lark 来源使用原 request/source fence。 基线规范

• 单次版本解析。 在同一合成 workload 下，首次准入的实际版本解析从 13 次降到 1 次，后三个新事件从各 6 次降到各 1 次，四次重投从各 2 次降到各 1 次。
• 保留来源授权与重投。 在 provider source read 中途撤销原绑定，两边都返回 command_rejected，均无新 Turn 或投递；四次重投仍各只有一条原 Session/Turn 的用户消息。
• 生产观测。 本轮为本机隔离验证；真实 Lark provider、生产锁尾延迟与分发后的观测仍待单独验证。

关键代码讲解

admit复用现有 scope，Core 仍按来源 fence确认原 App 和来源，重投仍沿原 journal。

对主干的风险 / Risks

值得关注的是版本复用会不会跨事件、或者掩盖授权变化。实际 scope 每次退出清空，同事件重投与读中撤销均保持原结果；没有新增持久缓存。

48 项 Lark 相关测试通过。两侧的实际输入、原请求身份和撤销结果一致。 Quick premerge 的 6 项直接检查和 2 项选中检查通过。 当前 base 的合并树可写、DCO 已核对。 小样本本地 warm median 约 409→323 ms，只说明这组 fixture；结论以解析次数与读回为依据。 远端 CI 未取样。

我的整体评价 / Verdict

同意 ce07338b1e7db73a1b3a8c6fa912df60b59564f0：独立对照证明减少重复解析，且原请求、重投和来源拒绝不变。 本轮为本机隔离验证；真实 Lark provider、生产锁尾延迟与分发后的观测仍待单独验证。

English verdict: APPROVE. The request-scoped revision reuse reduces real resolution work and preserves fresh binding checks and original-Turn replay.